Move dynamically allocated variables to static variables.#415
Conversation
…variable instead of variables on the heap. We don't need them on the heap as we know their size at build time, it'll reduce memory fragmentation and it'll make memory analysis easier.
… it was executing the button handler).
…eck the code is running from an IRQ before calling xQueueSendFromISR or xQueueSend)
|
I've just pushed new changes that should fix #327. I would be grateful if some of you could test the branch and confirm it's working fine :) |
|
I think these changes might be vulnerable to Static Initialization Order Fiasco issues.
|
I have compiled this branch and not seen any issues |
I thought that the compiler would construct the static variables in the order of declaration. In this case, Anyway, I've just checked with the debugger and SettingsController is init'd before DisplayApp. One way to ensure we are not vulnerable to this SIOF is to call the first LoadApp in DisplayApp::Start() instead of in the ctor(). This way, we'll be sure everything is constructed in time. |
…initialized in main() into Start()/Init() functions to avoid Static Initialization Order Fiasco (https://en.cppreference.com/w/cpp/language/siof). See #415 (comment).
…initialized in main() into Start()/Init() functions to avoid Static Initialization Order Fiasco (https://en.cppreference.com/w/cpp/language/siof). See InfiniTimeOrg/InfiniTime#415 (comment).
Initialize SystemTask, DisplayApp and HeartRateTask as global static variable instead of variables on the heap. We don't need them on the heap as we know their size at build time, it'll reduce memory fragmentation and it'll make memory analysis easier.
Heap usage is reduced from >6KB to ~2KB. Most of this memory is allocated by NimBLE.
Global heap and stack have also been reduced (4KB heap, 1KB stack)